1. The Field of the Invention
The present invention relates to distributed application programming models and, more particularly, to utilizing abstract descriptions to generate, exchange, and configure service and client runtimes.
2. Background and Relevant Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, Web browsing, and printing documents) include the exchange of electronic messages between a number of computer systems and/or other electronic devices via wired and/or wireless computer networks.
Networks have in fact become so prolific that a simple network-enabled computing system may communicate with any one of millions of other computing systems spread throughout the globe over a conglomeration of networks often referred to as the “Internet”. Such computing systems may include desktop, laptop, or tablet personal computers, Personal Digital Assistants (“PDAs”), telephones, or any other computer or device capable of communicating over a network.
In some environments, such as, for example, a service oriented architecture environment, connection endpoints (often and hereinafter referred to as “services”) communicate with one another to implement desired functionality. Desired functionality can be as simple as two services exchanging data. For example, a service consumer can send a service request message to a service provider, the service provider can receive and process the service request message, and the service provider can return a corresponding service response message to the service consumer. However, desired functionality can also be more complex, for example, involving a number of services exchanging messages to coordinate some activity. A service typically has some type of computer system (both hardware and software) that supports a corresponding offered connection.
Exchanged messages (e.g., service request messages and service response messages) can be defined in way that is understandable to each service (e.g., one or more service consumers and one or more service providers) involved in implementing desired functionality. Generally, messages can be defined in accordance with some standard, such as, for example, Distributed Component Object Model (“DCOM”), Common Object Request Broker Architecture (“CORBA”), or Web services. Web services can be further defined in accordance with various Web services specifications, such as, for example, Web Services Description Language (“WSDL”), Web Services Policy Framework (“WS-Policy”), etc.
For example, a service provider can describe its service using WSDL. The service provider can publish the description to a directory of services, for example, that uses Universal Description, Discovery, and Integration (“UDDI”). A service consumer can issue queries against the directory to locate a service and determine how to communicate with the service. Portions of the WSDL provided by the service provider are passed on to the service consumer in response to a query. The service consumer uses the WSDL portions to send a request to the service provider. In turn, the service provider provides an appropriate response to the service consumer.
In some environments, to generate a service, a developer writes source code (e.g., in C#, C++, or Visual Basic) in accordance with a specified programming model. The source code can then be compiled into a service type and the service type executed in a service runtime to provide the service to service consumers. However, service runtimes can be created in different ways and different programming models can implement distributed messaging functionality in different ways. For example, one programming model can implement a request message using one interface and a corresponding reply message using a second different interface. On the other hand, another programming model can implement both a request message and a corresponding reply message using a single interface that has separate methods. The single interface can have one method for the request message and a second different method for the corresponding reply message.
Different programming models can also be configured in accordance with different configuration options, such as, for example, security options, reliable messaging options, message logging options, connection throttling options, etc. Thus, two services that are designed to implement the same functionality (e.g., performing a mathematical operation) may implement the functionality differently.
Further, distributed applications are typically rigid in their programming models allowing only one programming model that is tightly coupled to their service runtime. Accordingly, for compatibility, a client runtime (e.g., at a service consumer) is typically required to utilize a client program or module developed in accordance with the same programming model as the server runtime. For example, if a service was developed using separate interfaces for request and reply messages or using particular security mechanisms, the service consumer must implement those as well. Failure to use a client program or module developed in accordance with the same programming model can prevent a client runtime from communicating with service runtime.
In many environments, there is a rigid coupling between a service description (or programming model and corresponding runtime. That is, a server defines its code and generates its description. To utilize the service runtime, a client downloads the service description and generates a proxy. However, subsequent, and even very minor, code changes at the server can cause the client and server to become incompatible. That is, due to the rigid coupling between service description and service runtime, changing even one configuration option or defined messaging pattern in a description document can result in an incompatible client runtime.
Changing programming models of a service runtime can also cause incompatibility with existing client runtimes. Further, disseminating information related to the new programming model can be difficult. For example, a developer of a client runtime may have to wait for publication of a new service description document before development of new client runtime can begin. Generation of a service description document may not occur until the service is complete and thus generation of service description document can lag behind deployment of a new service runtime based on a new programming model.
Unfortunately, when a service description document is not available or is incomplete in some way, it can be difficult for a client runtime developer to identify and correct incompatibility issues. Further, a client runtime developer may not have access to the service type source code written by the service runtime developer. Thus, the client runtime developer may have no way to determine new message patterns or other new configuration options associated with the new programming model. Accordingly, it may be that only through trial and error is the client runtime developer able to identify and correct incompatibility issues.
Therefore systems, methods, and computer program products for utilizing abstract descriptions to generate, exchange, and configure service and client runtimes would be advantageous.